A database is an organized collection of data. Databases commonly organize the data into segments, records, and data set groups. In some instances, database data may be divided into partitions. The IBM IMS™ High Availability Large Database (HALDB) is an example of a partitioned database. A partitioned database may store the data of each partition in a number of different data sets. Similarly, a non-partitioned database may store data in a number of data sets. To access the data in such a database, the database may access a specific data set. The names of these data sets may be stored in a database schema and/or catalog file. The database schema generally describes the organization of the database, and may include the size and name of the data sets storing the data of the database, the partition associated with each of the data sets, relationships between partitions, etc. The schema may itself be a data set or some other repository of data that can be modified.
A database administrator may desire to reorganize one or more partitions in a database for various reasons. Database reorganization includes changing some aspect of the data in the database. For example, reorganization may include rearranging the data to improve system performance. Reorganization can include restructuring operations. For example, reorganization of a database may include restructuring operations such as changing the limit keys for partitions, moving data between partitions, changing segment lengths, changing the data access method, changing the parameters that determine where to add new data, etc. For the purposes of this disclosure, most physical changes to the database, such as changing key lengths, may not be considered reorganizing, with the exception of adding segments to the end of the database.
Database reorganization typically requires the database to be taken offline for some amount of time. For example, reorganizing a database may include creating a shadow, or copy, of the data, reorganizing the shadow, taking the database offline, and swapping the data sets of the database with the data sets of the shadow. This swapping generally occurs by renaming the database data sets to a new name and then renaming the shadow data sets to the former names of the database data sets. In such a swap, the database is taken offline so that the names of the data sets can be changed in the operating system catalog files. Renaming a data set requires exclusive accesses to the catalog file, which means applications, such as the database environment, cannot be online and using files during the rename. Furthermore, renaming generally occurs serially, so that other programs may interrupt a rename operation for multiple files, further contributing to the length of the database outage.
But databases have grown and may now have 10,000 data sets. Renaming hundreds or even thousands of data sets may take minutes rather than seconds because the names must be changed serially, one after the other. For businesses such as banking and other financial institutions, Internet retailers, and the travel industry, for example, such outages can have undesirable consequences, causing loss of customers, sales, and opportunities.